…Permissions.

-----------------------------------
The current setup for deleting a project involves conflicting permission checks. In the resource class function, users with a Project Manager (PM) role are allowed to delete projects. However, in the service function responsible for project deletion, the check only permits organization managers or system administrators to perform this action.

To address this inconsistency in permission checks, this commit streamlines the process. It eliminates the permission check within the service function, thereby enabling users with PM roles within a project to successfully initiate project deletions.

… correct error response can be returned

--------------------------------------------------------------------

Previously, we utilized the same error reason, namely "USER_NOT_ON_ALLOWED_LIST," for two distinct situations:

1. When a user, who is blocked, attempts to map/validate a task.
2. When a user lacks the necessary permissions to map/validate.

To enhance clarity and precision in error reporting, we have introduced a distinct error reason for the scenario where a user is blocked. This modification allows us to deliver more accurate and contextually relevant error messages, ultimately improving the user experience and troubleshooting process.

…s this is already checked in resource function

-----------------------
After the introduction of new exception classes on backend the error response format is changed. As in new error response error subcode should be accessed on error.sub_code this commit handles this case.
Also change in subcode to identify project is private and cannot be accessed by user has been addressed.